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Abstract 


This  paper  describes  TAXIS,  a  language  for  the  design 
of  Interactive  Information  Systems  (e.g.,  credit  card  verifica¬ 
tion,  student-course  registration  and  airline  reservations). 

TAXIS  offers  (relational)  database  management  facilities,  a  means 
of  specifying  semantic  integrity  constraints  and  an  exception¬ 
handling  mechanism,  integrated  into  a  single  language  through 
the  concepts  of  cIclaa,  ph.op<i>ity  and  the  IS- A  (generalization) 
no. nations  hip .  The  paper  includes  a  description  of  the  main 
constructs  of  TAXIS  and  illustrates  their  usefulness  with 
examples . 


KEYWORDS  AND  PHRASES:  Applications  programming,  information 
system,  relational  data  model,  abstract  data  type,  semantic 
network,  exception  handling. 


2 


1.  INTRODUCTION 

1 . 1  Motivation 

A  primary  goal  of  database  management  is  the  reduction  of 
software  costs  by  promoting  data  independence.  In  the  database 
literature,  practical  aspects  of  the  development  of  applications 
software  that  use  a  database  system  are  often  treated  as  peripheral 
to  the  main  thrust  of  database  research.  Until  recently, 
applications  programming  has  usually  been  considered  in  the  context 
of  a  data  sublanguage  embedded  in  a  conventional  applications 
programming  language.  Some  of  the  better  examples  of  this  approach 
include  papers  by  Date  [5]  and  Schmidt  [17] . 

A  more  recent  trend  is  to  design  the  programming  language 

with  database  facilities  as  a  single  unit  [16,22].  This  paper  takes 

a  step  along  this  path  by  presenting  an  applications  programming 

language  that  tightly  integrates  data  with  the  procedures  that  use 

it  (in  the  style,  say,  of  SIMULA  [4]). 

t 

Our  language,  called  TAXIS  ,  is  designed  primarily  for 
applications  systems  that  are  highly  interactive  and  make  substan¬ 
tial  use  of  a  database.  These  applications,  which  we  call 
interactive  information  systems  (abbr.  IIS),  are  characterized  by 
their  handling  of  large  volumes  of  transactions  that  are  short,  of 
predictable  structure,  and  update  intensive.  Examples  include 
credit  card  verification,  student-course  registration,  and  airline 
reservations.  By  applying  our  tools  to  a  more  limited  domain,  we 
can  customize  them  to  the  domain.  Also,  by  defining  our  problem 

t 

Taxis  (xa^is) :  Greek  noun,  means  order  as  in  "law  and  order"  or 
class  as  in  "social  class",  "university  class",  etc. 
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more  narrowly  than  that  of  "applications  systems",  it  will  be 
easier  to  evaluate  the  efficacy  of  our  approach. 

In  the  future,  we  see  TAXIS  at  the  center  of  a  program¬ 
ming  system  that  would  permit  a  designer  to  interactively  build  an 
IIS  with  the  help  of  specialized  text-editing  and  graphics 
facilities.  The  system  would  include  a  relational  database  manage¬ 
ment  system  (abbr.  DBMS).  The  DBMS  provides  an  interface  into 
which  the  database  operations  of  the  IIS  can  be  compiled. 


1 . 2  Design  Principles 

TAXIS  is  eclectic,  combining  concepts  from  three  areas  of 
computer  science  research:  Artificial  Intelligence  (abbr.  AI),  Pro¬ 
gramming  Languages  and  Database  Management.  From  AI  we  have  used 
the  concept  of  semantic  network  for  data  and  procedure  modelling 
[2,11].  From  Programming  Language  we  have  borrowed  the  concept  of 
abstract  data  type  [12,18]  and  exception  handling  [21].  Finally, 
from  Database  Management  we  have  built  on  the  concept  of  a 
relational  database  [8]. 

These  ideas  are  married  into  a  concise  language  framework, 
yielding  a  novel  and  powerful  collection  of  facilities.  First, 
the  semantic  network  modelling  constructs  represent  a  qualitative 
improvement  in  abstraction  mechanisms  over  conventional  program¬ 
ming  languages .  Database  operations  can  work  on  hierarchies  of 
objects,  instead  of  independent  tuples  and  relations  (similar 
to  [19]).  Data  can  thereby  be  manipulated  at  varying  levels  of 
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abstraction.  We  extend  our  semantic  structures  beyond  relations 
and  apply  them  equally  to  procedures, integrity  constraints,  and 
exception  handling. 

Second,  by  associating  operations  with  the  data  they  use, 
the  semantics  of  the  dat&b&A z  can  be  represented  in  the  applications 
program.  This  is  in  contrast  to  the  sharp  distinction  between  DDL 
and  DML  in  most  database  languages.  The  semantic  information  can 
be  used  by  the  compiler  to  solve  many  integrity,  security  and 
concurrency  problems  at  compile  time. 

Finally,  since  the  application  is  described  in  a  formal 
semantic  model,  "meta-level"  commands  allow  the  application 
description  itself  to  be  manipulated  by  programming  language 
commands.  This  permits  database  administrator  functions  to  peruse 
the  logical  design  on-line. 

Four  principles  guided  much  of  the  TAXIS  design: 

1.  The  language  must  offer  relations  and  associated 
operations  for  database  management,  transactions  for  the  specification 
of  application  programs,  and  exception-handling  facilities  to 
enhance  the  development  of  interactive  systems. 

2.  Each  conceptual  object  represented  in  the  language  must 
have  associated  semantics  that  involve  both  a  behavioral  and  a 
structural  component.  These  semantics  are  expressed  in  terms  of  the 
notions  of  class,  property  and  the  IS-A  hierarchy  (cf.  ’generaliza¬ 
tion  '  in  [  19 ] )  . 

3.  As  much  of  the  language  as  possible  should  be  placed  into 
the  framework  of  classes,  properties  and  the  IS-A  hierarchy. 
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4.  The  schema  (i.e.  the  collection  of  classes  along  with 

their  properties  and  the  associated  IS-A  hierarchy)  should  be 
compilable  into  a  language  such  as  PASCAL,  enriched  with  a  relation 
data  type  and  associated  operations  (as  proposed,  for  instance, 
in  [17]). 

The  first  principle  is  a  consequence  of  the  intended 
scope  of  the  language.  The  second  reflects  our  belief  that  much  of 
the  difficulty  of  designing  and  implementing  IISs  (usually  translated 
into  high  costs  of  initial  implementation  and  maintenance)  is  due 
to  the  lack  of  appropriate  programming  constructs  in  "conventional” 
languages  (e.g.,  COBOL  and  PL/I)  for  handling  the  semantics  of  any 
one  application.  The  third  and  fourth  principles  are  the  results 
of  our  concern  for  linguistic  uniformity  and  efficiency.  We 
consider  both  of  them  quite  important  given  the  multiplicity  of 
sources  of  ideas  and  the  complexity  of  the  problem  at  hand. 

Section  2  of  the  paper  discusses  the  basic  entities  that 
constitute  a  TAXIS  program.  Section  3  describes  the  IS-A  hierarchy 
as  an  organizational  principle  (abstraction  mechanism)  for  the 
classes  constituting  a  program.  In  Section  4  we  present  more 
details  about  the  different  categories  of  classes  .  Concluding 
remarks  and  directions  for  further  research  appear  in  Section  5. 

The  presentation  of  the  language  is  rather  informal  and 
necessarily  sketchy  due  to  space  limitations.  The  interested 
reader  is  referred  to  [14,25]  for  more  details. 
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2.  OBJECTS  AND  PROPERTIES 

There  are  three  types  of  objects  in  TAXIS:  token*  which 
represent  constants,  aZa**e*  which  describe  collections  of  tokens, 
and  metacla** &*  which  describe  collections  of  classes. 

2 . 1  Tokens  and  Classes 

Tokens  are  the  constants  of  a  TAXIS  program.  For 
example,  john-smith  (representing  the  particular  person  called 
John  Smith),  » SMITH, JOHN , B »  (representing  the  string  "SMITH, JOHN, B") 
and  7  (representing  the  number  7)  are  all  tokens.  Tokens  are 
denoted  throughout  the  paper  by  identifiers  in  lower-case  letters, 
strings  delimited  by  single  quotes  and  numerals. 

A  class  is  a  collection  of  tokens  sharing  common  proper¬ 
ties.  If  a  token  t  is  an  element  of  the  collection  associated 
with  a  class  C  we  say  that  t  l*  an  tn*tance  ofi  C.  It  may  be  helpful 
for  the  reader  to  compare  TAXIS  classes  with  SIMULA  classes  or 
programming  language  types  as  points  of  reference. 

Some  sample  classes  are  PERSON,  whose  instances  are 
tokens  such  as  john-smith,  representing  particular  persons, 
PERSON-NAME,  whose  instances  are  (string)  tokens,  such  as 
’ SMITH, JOHN, B '  that  can  serve  as  proper  names,  and  INTEGER,  whose 
instances  are  integers  such  as  7.  We  will  use  identifiers  in 
capital  letters  to  denote  classes. 

We  call  the  collection  of  all  tokens  which  are  instances 
of  a  class  C  the  exten*ton  o fa  C. 
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2  .  2  Properties 

Classes  and  tokens  have  properties  through  which  they 
can  be  related  to  other  classes  and  tokens.  Some  of  the  properties 
that  may  be  associated  with  the  class  PERSON  represent  the 
following  information: 

"each  person  has  a  name,  an  address,  an  age  and  a 
phone  number" 

"each  person’s  name  consists  of  a  first  and  last  name 
and  possibly  a  middle  initial" 

For  tokens,  properties  represent  specific  facts  rather  than 

abstract  rules  such  as  those  presented  above.  Thus,  john-smith 

will  have  properties  expressing  facts  such  as 

" j ohn- smi th ’ s  name  is  ’ SMITH, JOHN, B ' ,  his  address  is 
38  Boston  Dr.,  Toronto,  his  age  is  32  and  his 
telephone  number  is  762-4377" 

Properties  are  triples  consisting  of  one  or  more  6u.bje.c.t<t>, 

an  a.ttsii.bu.t<z  and  a  pficp&fity  vatua  (or  p-v&fue.)  .  For  example, 

PERSON  may  have  the  following  properties: 

<PERS0N ,  name,  PERSON-NAME> 

<PERSON ,  address,  ADDRESS -VALUE> 

<PERSON ,  age,  AGE-VALUE> 

<PERSON ,  phone#,  PHONE-VALUE> 

The  same  applies  for  properties  of  tokens,  i.e., 

(john-smith,  name,  ’ SMITH , JOHN , B ' ) 

(john-smith,  address,  j ohn-smith ’ s -address) 

(john-smith,  age,  32) 

(john-smith,  phone#,  7624377) 
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Note  that  the  properties  of  PERSON  provide  information  about 
the  structure  of  instances  of  that  class,  while  the  properties 
of  john-smith  specify  the  structure  of  the  token  itself.  This 
distinction  was  already  made  in  the  notation  just  introduced  for 
properties,  with  the  properties  of  a  class  delimited  by  angular 
brackets  and  those  of  a  token  by  parentheses.  We  call  the  former 
type  of  property  defitnttto  na.1  and  the  latter  factual. 

Some  properties  may  have  more  than  one  subject.  For 

example , 

< (FLIGHT#,  DATE),  fit,  FLIGHT> 

defines  a  (definitional)  eomptex  pA.opeA.ti/  with  subjects  the  classes 
FLIGHT#  and  DATE  and  p-value  the  class  FLIGHT.  This  property  may 
represent  the  information: 

"each  combination  of  a  flight  number  and  a  date  has 
an  associated  flight" 

As  the  reader  may  have  suspected,  there  is  a  strong 
relationship  between  the  definitional  properties  of  a  class  and 
the  factual  properties  of  its  instances.  The  relationship  may  be 
expressed  in  terms  of  the  following  pA.opeA.ty  tnductto n  pA.tnetple- 
VA.opeA.ty  I ndnetto n  ?A.tnctple :  The  definitional  properties 
of  a  class  induce  factual  properties  for  its  instances. 

If  classes  C, , . . . ,C  are  the  subjects  of  a  definitional 
complex  property  with  attribute  p,  the  TAXIS  expression 
(C^ ,  . .  .  ,C  )  ..  p  (or  C^..  p  if  n=l)  returns  the  p-value  of  that 
property.  For  example,  PERSON.. age  returns  the  class  AGE-VALUE, 
while  (FLIGHT# , DATE) .. fit  returns  FLIGHT.  In  other  words,  ".."  is 
a  "schema  selector"  and  allows  the  traversal  of  the  schema  defined 
within  a  TAXIS  program  by  its  classes  and  their  definitional 


9 


properties.  For  the  operator  to  be  unambiguous,  no  two 
definitional  properties  can  have  the  same  subject(s)  and  attribute. 

Turning  to  factual  properties,  if  < (C^ , . . . , C  ) ,p ,C>  is 
a  definitional  property  and  t^  is  an  instance  of  C.,  1  <  i  <  n, 
then  (t-^ ,  .  .  .  ,  tn)  .p  (or  t^.p  if  n=l)  evaluates  to  an  instance  of  C, 
say  t,  such  that  ( (t^ , . . . , tn) ,p,t)  is  a  factual  property.  Thus, 
j ohn-smith . age  returns  32  while  (802,  may-1-1979) .fit  returns 
the  particular  flight  associated  with  those  two  tokens  through 
the  "fit”  property  (i.e.,  the  property  with  attribute  ’fit'). 


2 . 3  Metaclasses 

If  one  wishes  to  represent  the  information 
"the  average  age  of  (known)  persons  is  28" 


or 


"the  number  of  (known)  flights  is  473" 
he  may  be  tempted  to  express  these  facts  by 
<PERSON,  average-age,  28> 

< FLIGHT ,  cardinality,  473> 

However,  this  representation  is  incorrect  since  definitional 
properties  represent  information  about  the  structure  of  instances 
of  a  class,  not  the  class  itself.  Instead,  factual  properties 
must  be  used  to  represent  these  facts: 

(PERSON,  average-age,  28) 

(FLIGHT,  cardinality,  473) 

But  to  be  consistent  with  the  Property  Induction  Principle,  these 
factual  properties  must  be  induced  by  definitional  properties 
which  have  the  classes  PERSON  and  FLIGHT  as  instances.  This 
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observation  leads  to  the  introduction  of  a  third  type  of  TAXIS 
object  called  rmta.cl<u>A  .  A  metaclass  is  similar  to  a  class  in 
every  respect,  except  that  its  instances  are  classes  rather  than 
tokens.  For  instance,  the  metaclass  PERSON-CLASS  may  be  defined 
with  instances  all  classes  whose  instances  denote  persons  (e.g. 
PERSON,  STUDENT,  EMPLOYEE,  MANAGER).  Then  the  definitional  property 

<PERSON-CLASS ,  average-age,  AGE-VALUE> 
allows  the  association  of  an ’’average  -  age"  factual  property  with 
every  instance  of  PERSON- CLASS . 

(PERSON,  average-age,  28) 

(STUDENT,  average-age,  19)  etc. 

We  will  refer  to  the  relationships  between  a  token 
(class)  and  a  class  (metaclass)  it  is  an  instance  of  as  the 
7 WSTAWCE-DF  relationship. 

Generally,  a  TAXIS  program  includes  tokens  which  can 
only  have  factual  properties  associated  with  them,  classes  which 
can  have  factual  and  definitional  properties,  and  metaclasses 
which  can  only  have  definitional  properties.  For  a  more  sophisti¬ 
cated  treatment  of  the  INSTANCE-OF  relationship  which  allows 
an  arbitrary  number  of  levels  of  metaclasses  see.  [11]  and  [20]. 

We  expect  that  the  three  levels  allowed  in  TAXIS  will  suffice  for 
most  practical  situations. 

For  metaclasses,  we  use  identifiers  in  capital  letters 
which  end  in  -  CLASS.  As  with  classes,  the  collection  of  all 
instances  of  a  metaclass  is  called  its  extension. 


11 


2 . 4  Examples 

Classes  and  metaclasses  are  defined  by  specifying  their 
name  and  their  simple  properties.  For  example,  the  metaclass 
PERSON-CLASS  can  be  defined  by 

m zta.c.ta.6 4  PERSON-CLASS  u)tth 
cLttfU.bute.-psiope.fit'Le.A 

average -age:  AGE-VALUE; 

end 

Here  PERSON-CLASS  is  defined  to  have  one  simple  (i.e.  non-complex) 
property 

<PERSON-CLASS  average-age  AGE-VALUE> 

The  metaclass  definition  also  specifies  that  the  property  defined 
is  of  the  a.ttfitbu.t2.-pfio p2.fity  category  which  means  that  the 
"average  -  age"  factual  property  of  an  instance  of  PERSON-CLASS  may 
change  with  time.  Generally,  every  definitional  property  defined 
in  a  TAXIS  program  is  classified  into  a  unique  pn.op2.fity  c.a.t2.gofiy 
at  the  time  of  its  definition  which  determines  the  functional 
and  operational  characteristics  of  the  property. 

Property  categories  allow  the  specification  of  informa¬ 
tion  such  as  that  the  function  defined  by  a  property  is  time 
varying  or  1-1  or  should  be  used  in  a  particular  manner  when 
instances  of  its  subject(s)  are  created.  The  examples  to  follow 
illustrate  the  different  uses  of  property  categories. 

The  class  PERSON  can  now  be  defined  as  an  instance  of 
the  metaclass  PERSON-CLASS  by 
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PERSON-CLASS  PERSON  with 
k<Lyt> 

person-id:,  (name,  address); 
cka.siac.teJi'LA 

name:  PERSON -NAME; 
address:  ADDRESS -VALUE ; 
phone#:  PHONE-VALUE; 

age:  AGE -VALUE; 

status:  STATUS -IN -CANADA; 

end 


According  to  this  definition,  PERSON  has  two  attribute  (i.e. 
time-varying)  properties  and  three  characteristic  properties, 
which  are  time -invariant .  The  key  property  described  in  the 
definition  of  PERSON  specifies  the  complex  property 

<  (PERSON-NAME,  ADDRESS -VALUE) ,  person-id,  PERSON> 

Thus  ( 'SMITH, JOHN,B ' ,  j ohn-smith ' s -address) .person-id  returns 
the  person  with  ’SMITH, JOHN, B '  as  name  and  j ohn-smith ' s -address 
as  address,  if  any.  If  there  is  none,  the  expression  returns  the 
special  TAXIS  token  nothing. 

The  class  FLIGHT  can  be  defined  in  a  similar  fashion: 

VARIABLE-CLASS  FLIGHT  with 
key* 

fit:  (flight#,  date); 

C.ka.SlCLCt&fl'LAti.CA 

flight#:  { | 1 :  :  999 | } 

department:  [|city:  CITY,  country:  COUNTRY | ] ; 
destination:  [|city:  CITY,  country:  COUNTRY]]; 
aircraft:  AIRCRAFT -TYPE ; 
date:  DATE -VALUE; 
attulb  ute.-  pno  p  zsLtleA 

seats -left :  NONNEGATIVE- INTEGER; 

end 


Here  VARIABLE  -  CLASS  stands  for  a  special  metaclass  whose  instances 
can  have  their  collections  of  tokens  changed  in  terms  of  explicit 
insertions  or  removals.  Thus,  since  FLIGHT  is  an  instance  of 
VARIABLE-CLASS  it  can  have  tokens  added  to  or  removed  from  its 
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collection  of  instances.  Clearly,  variable  classes  behave  very 
much  like  relations  [  3  ] .  PERSON  can  also  be  made  an  instance 
of  the  metaclass  VARIABLE -CLASS ,  in  addition  to  its  being  an 
instance  of  PERSON-CLASS,  by  relating  the  metaclasses  PERSON-TYPE 
and  VARIABLE -CLASS  through  the  IS-A  relationship.  More  on  this 


in  the  next  section. 

The  class  defined  by  {  |  1 :  :  9 9 9  !  }  is  dz^vmd  in 

the  sense  that  it  has  a  finite,  time - invar iant  collection  of 
instances  which  includes  all  integers  from  1  to  999.  Since  this 
class  doesn’t  have  an  associated  name,  it  can  only  be  referenced 
through  expressions  such  as  PERSON .. flight# . 

The  class  defined  by  {|city:  CITY,  country:  COUNTRY|} 
has  as  instances  all  tuples  with  first  component  an  instance  of 
CITY  and  second  an  instance  of  COUNTRY.  Classes  such  as  this  are 
instances  of  the  special  metaclass  AGGREGATE -CLASS .  Generally,  an 
instance  of  AGGREGATE-CLASS  has  a  collection  of  instances  which  is 
the  cross  product  of  the  collections  of  instances  of  classes  that 
serve  as  p-values  of  its  characteristic  properties.  In  this 
respect,  aggregate  classes  are  quite  different  from  variable  classes. 

In  other  words,  if  aggregate  class  C  has  characteristic 
properties  p^,...,pn  with  p-values  C^,...,Cn  respectively,  and  if 
the  extensions  of  these  classes  are  ext  (C^  ,  cr)  ,  .  .  .  ,  ext  (C  ,  a)  in 
some  database  state  a,  then 

ext(C,a)  =  ext (C^ ,a) xext (C2 ,a) x . . . xext (Cn,a) 
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The  class  [|city:  CITY,  country:  COUNTRY | ]  could  have 
been  defined  separately 

AGGREGATE -CLASS  LOCATION  volth 
c  hcLfia.  at  t-Lai> 

city:  CITY; 
country:  COUNTRY; 

end 

with  LOCATION  replacing  [|city:  CITY,  country:  COUNTRY|].  If  that 
second  method  were  used, 

FLI GHT .. departure  =  FLIGHT .. destination 

With  the  original  definition  of  FLIGHT,  however,  the  above  equality 
does  not  hold.  In  other  words,  each  class  definition  that  appears 
in  a  TAXIS  program  causes  the  introduction  of  yet  another  class  in 
the  schema  described  by  the  program. 

Turning  to  some  of  the  classes  mentioned  in  the 
definitions  presented  so  far,  let  us  first  define  PHONE-VALUE  as 

FORMATTED -CLASS  PHONE -VALUE  mJitk 

(|  ’(’  |}  @  REPEAT (DIGIT, 3)  @  (|  |}  @ 

REPEAT (DIGIT , 7) 

o,nd 


Formatted  classes  (i.e.  instances  of  FORMATTED-CLASS)  have  as 
instances  all  strings  which  are  consistent  with  a  given  string 
pattern.  In  particular,  PHONE-VALUE  instances  have  the  format 
' (ddd) ddddddd ’  where  d  is  any  digit.  Here  (|  T)’  |}  defines  a 

class  with  only  instance  the  string  ?)’,  and  A  @  B  defines  a  class 
with  instances  strings  obtained  by  concatenating  an  instance  of  B 
to  an  instance  of  A.  Moreover, 

REPEAT(A,n)  e  A  @  A  @  ...  @  A  (n  times) 

Finally,  DIGIT  is  assumed  to  be  the  class  { [  '  0  '  ,  '  1 1  ,  .  .  .  ,  f 9  1  |  }  . 
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It  was  mentioned  in  the  introduction  that  all  TAXIS 
constructs  are  treated  within  the  framework  described  so  far.  Thus 
transactions  are  classes  too.  For  example,  the  transaction 
RESERVE-SEAT  may  be  defined  as  follows: 

TRANSACTION-CLASS  RESERVE-SEAT  with 
paH.am2.tzfi- 116 t 

pl:  (p,  f ) ; 
local 6 

p:  PERSON; 
f:  FLIGHT; 
x:  INTEGER; 
pH2H2C[6 

seats-left?  :  f.seats-left  >  0; 
actions 

make -reservation : 

ln6  2Ht-obj cat  in  RESERVATION  with 
person  p,  flight  f 

decrement-seats:  f.seats-left  +-  f.seats-left  -  1; 
assign- aux-variable  :  x  f.seats-left; 

H2tuHn6 

rtrn:  x; 

2nd 

The  above  definition  specifies  the  parameter  list  of  RESERVE-SEAT 
through  the  paHamztzH-ll6t  property  which  defines  a  complex 
property 

< (PERSON, FLIGHT) ,pl,  RESERVE -SEAT> 

Local  properties  define  either  parameters  or  local  variables  of 
the  transaction.  The  body  of  the  transaction  is  given  in  terms  of 
zero  or  more  pH2H2qu.l6ltz,  action  and  H26u.lt  properties  whose 
p-values  are  invariably  expressions.  Finally,  the  Hztu.Hn6  property 
associates  with  a  transaction  an  expression  to  be  evaluated  when 
execution  of  the  body  of  the  transaction  has  been  completed.  The 
value  of  the  expression  is  also  the  value  returned  by  the  trans- 


sac  tion  . 
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It  is  assumed  in  the  definition  of  RESERVE-SEAT  that 
RESERVATION  has  already  been  defined  as  a  variable  class  and  that  it 
has  two  characteristics  with  attributes  person  and  flight  respectively. 
Thus  the  cftt- ob  j  cct  expression  inserts  another  instance  into 

the  extension  of  this  class  and  sets  its  two  characteristic  proper¬ 
ties  to  p  and  f  respectively.  The  other  two  action  property 
decrement  the  seats-left  property  of  flight  f  by  one  and  set  the 
local  variable  x  to  the  value  to  be  returned  by  the  transaction. 

A  transaction  class  is  similar  to  a  variable  class  in 
that  it  has  a  time-varying  extension.  When  an  expression  involving 
a  call  to  RESERVE-SEAT  is  evaluated,  a  new  token  is  first  created 
and  added  to  the  extension  of  RESERVE -SEAT .  This  token  is  essen¬ 
tially  an  execution  instance  of  RESERVE-SEAT  and  the  factual 
properties  associated  with  it  indicate  the  values  of  local  variables 
at  any  one  time.  In  fact,  for  the  expressions  which  appear  inside 
the  transaction,  mention  of  a  local  variable  or  parameter,  i.e. 
p,  f  or  x  for  RESERVE-SEAT,  is  interpreted  as  equivalent  to  self.p, 
self.f,  self.x  where  "self" denotes  the  execution  instance  with 
respect  to  (w.r.t.)  which  these  expressions  are  evaluated.  Some¬ 
thing  analogous  applies  to  pficficqul bite,  action,  fui&u.lt  and  n.ctu> in-6 
properties  which  initially  have  p-value  unknown  (another  special 
TAXIS  token),  until  the  corresponding  expression  has  been  evaluated. 
From  that  point  on,  the  p-value  of  such  a  property  is  the  value 
returned  by  the  expression.  Thus  if  the  identifier  make  -  reservation 
appears  in  an  expression,  before  the  make  -  reservation  action  property 
is  evaluated  its  value  is  unknown ,  while  after  it  is  the  value 
returned  by  the  ln6ch.t-obj  cct  expression. 


17 


As  mentioned  earlier,  execution  of  a  transaction  begins 
by  adding  a  token  to  the  extension  of  the  transaction  (class) . 
Execution  then  proceeds  by  evaluating  each  prerequisite  p-value 
expression  to  make  sure  that  it  returns  the  value  tn. ue  .  If  any  of 
the  prerequisite  expressions  are  found  to  have  a  value  other  than 
th.u.2.,  an  except  on  is  said  to  arise  and  execution  is  suspended. 
Otherwise,  action  expressions  are  evaluated  and  then  result 
expressions,  which  must  also  return  £n.mo,  values.  Thus  prerequisite 
and  result  properties  can  be  thought  of  as  preconditions  and 
postconditions  which  must  be  satisfied  if  execution  of  the  transac¬ 
tion  is  to  be  meaningful.  If  they  are  not,  an  exception  is  raised 
and  an  exception-handling  transaction  is  called  to  correct  the 
situations.  The  exception-handling  mechanism  of  TAXIS,  is 
discussed  in  section  4.4. 

When  the  p-value  of  a  definitional  property  < (C^ , . . .  ,G  ) ,p ,T> 
is  a  transaction,  the  meaning  of  the  property  changes  in  that  T 
specifies  not  the  type  of  p-values  of  factual  properties  induced 
by  <  C C ,  .  .  .  ,C  )  ,p ,T>  ,  but  rather  an  algorithm  for  getting  them. 

For  example,  suppose  the  property 

<PERSON,  birthdate,  COMPUTE -BIRTHDATE> 
is  added  to  the  definition  of  PERSON  where 

£A.a.n&a.c££o  n  COMPUTE  -  BIRTHDATE  w££k 
pcLfLCumtdfi 

pl  :  (  P  )  ; 

rt  :  this-year  -  p . age ; 

end 
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and  "this -year" is  an  identifier  that  denotes  the  current  year. 
Clearly,  to  every  particular  person  this  property  associates  not 
an  instance  of  COMPUTE -BIRTHDATE  but  rather  a  token  returned  by 
the  p-value  of  the  "rt"  property. 

This  convention  of  treating  transactions  as  means  for 
obtaining  p-values  rather  than  as  types  of  p-values  is  consistent 
with  the  SIMULA  class  concept.  Thus,  in  TAXIS 
p . birthdate  e  COMPUTE -BI RTHDATE (p) 
where  p  is  an  instance  of  PERSON.  Similarly,  for  the  parameter- 
list  complex  property  associated  with  RESERVE-SEAT 
(prsn,  flt).p;  =  RESERVE  -  SEAT (prsn,  fit) 
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3.  THE  IS -A  HIERARCHY 

We  envision  a  TAXIS  program  as  a  large  collection  of 
tokens,  classes  and  metaclasses  interconnected  through  their 
properties.  Perhaps  the  most  important  feature  of  TAXIS  is  the 
facility  it  provides  for  organizing  the  collection  of  classes  and 
metaclasses  into  a  hierarchy  (taxonomy) . 

3 . 1  Preliminaries 

The  IS-A  (generalization)  relationship  is  defined  over 
classes  and  metaclasses.  Informally,  we  say  that  (A  IS-A  B)  where 
A,  B  are  both  classes  (metaclasses)  if  every  instance  of  A  is 
an  instance  of  B.  For  example,  (ADULT  IS-A  PERSON)  specifies  that 
"every  adult  is  a  person"  and  (CHILD  IS-A  PERSON)  that  "every 
child  is  a  person". 

If  (A  IS-A  B)  then  every  definitional  property  of  B  is 
also  a  definitional  property  of  A.  Moreover,  A  can  have  additional 
properties  B  does  not  have  at  all,  or  it  can  redefine  some  of  the 
properties  of  B.  For  example,  the  class  ADULT  inherits  the  "name", 
"address"  and  "phone  #"  properties  of  PERSON  but  must  redefine 
the  "age"  property  by  restricting  "age"  p-values  to  instances  of 
the  class  OVER-18.  Similar  remarks  apply  for  CHILD  which,  in 
addition,  has  the  "guardian"  property  that  PERSON  does  not  have  at 
all.  In  defining  the  classes  ADULT  and  CHILD,  one  need  not  mention 
the  properties  these  classes  share  with  PERSON: 
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VARIABLE -CLASS  ADULT  it>-a  PERSON  with 

CLttK i  b  U.  t  <L  -  P n 0  p  £ £-6 

age  :  UNDER- 18; 
guardian:  ADULT; 

end 

Properties  cannot  be  redefined  arbitrarily.  For  example,  redefini¬ 
tion  of  ’’age"  only  makes  sense  if  (UNDER-18  IS-A  AGE-VALUE).  As 
the  reader  may  have  suspected,  the  IS-A  relationship  referred 
to  above  is  the  reflexive  transitive  closure  of  the  relationship 
f-6-a  used  in  class  definitions. 

3 . 2  IS-A  Relationship  Postulates 

The  formal  properties  of  the  IS-A  relationship  can  be 
summarized  in  terms  of  the  following  postulates: 

I.  All  classes  (metaclasses)  constituting  a  TAXIS  program 
are  organized  into  an  IS-A  hierarchy  in  terms  of  the 
binary  relation  IS-A  which  is  a  partial  order. 

II.  There  is  a  most  general  (maximum)  and  a  most  specialized 
(minimum)  class  w.r.t.  IS-A  called  respectively  ANY  and 
NONE.  Similarly,  there  is  a  most  general  and  a  most 
specialized  metaclass  called  respectively  ANY-CLASS 
and  NO-CLASS. 

III.  (Ex-ten^Y  o  nal  IS-A  :  If  (A  IS-A  B)  for  classes 

(metaclasses)  A  and  B  then  every  instance  of  A  is  also 
an  instance  of  B. 

(StfiLLdtutiCLl  IS-A  Con6tn.aZnt\ :  If  (A  IS-A  B)  and  B  is  the 
subject  of  a  definitional  property  <  (C^  ,  . . . ,B , . . . ,C  ) ,p ,D> 


IV. 
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then  A  is  also  the  subject  of  a  definitional  property 
<  (C^ , . . . ,A, . . . ,C  ) ,p ,E>  and  moreover  (D  IS-A  E)  . 

Note  that  these  postulates  define  neee^ia^iy  not  sufficient 
conditions  for  the  IS-A  relationship  to  hold. 

It  is  assumed  that  there  exist  classes  ANY - FORMATTED , 
ANY-VARIABLE ,  ANY -TRANSACT ION ,  etc.,  which  are  specializations  of 
ANY  and  below  which  one  finds  all  formatted  classes,  variable 
classes,  etc.  For  example,  the  definition  given  earlier 

VARIABLE -CLASS  FLIGHT  with 

•  •  • 

end 

places  FLIGHT  below  ANY-VARIABLE  and  is  therefore  equivalent  to 

VARIABLE-CLASS  FLIGHT  i6-a  ANY-VARIABLE  with 

•  •  • 

end 

For  metaclasses  the  IS-A  hierarchy  must  be  defined 
explicitly  by  the  TAXIS  user.  For  example,  the  metaclass  PERSON- 
CLASS  should  be  a  specialization  of  VARIABLE  -  CLASS ,  as  suggested 
in  section  2.4  and  for  this  purpose  its  definition  should  be 
changed  to 

metadata  PERSON-CLASS  iA-a.  VARIABLE-CLASS  with 
. . .  (as  before) 

end 

After  this  change,  all  instances  of  PERSON-CLASS  are  also 
instances  of  VARIABLE- CLASS  according  to  postulate  III  and  there¬ 
fore  PERSON  is  a  variable  class. 

The  Hasse  diagram  of  the  IS-A  relationship  need  not  be 
a  tree.  For  example,  the  definition 
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PERSON-CLASS  MALE -STUDENT  U -a  MALE,  STUDENT  with 

•  •  • 

end 

makes  MALE-STUDENT  a  specialization  of  MALE  and  STUDENT  which  may 
not  be  IS-A-comparable . 

The  class  ANY  has  as  instances  all  tokens  available  to  a 
TAXIS  program,  while  NONE  has  no  instances  at  all.  Similarly, 
ANY-CLASS  has  all  classes  as  instances  while  NO-CLASS  has  no 
instances  at  all. 

3 . 3  More  on  Seat  Reservations 

We  return  to  the  world  of  persons , flights  and  seat 
reservations  to  illustrate  the  use  of  the  IS-A  hierarchy. 

First,  let  us  define  a  few  specializations  of  previously 
defined  classes. 

INTERNATIONAL-FLIGHT#  :=  {  |  500:  :999|  }  U-cl  FLIGHT  ..  flight# 

FLIGHT#  -  WITHIN  -  CANADA  :=  {  |  1 :  :  499  |  }  U-a  FLI GHT  ..  flight# 
places  the  finitely  defined  classes  with  extensions  the  ranges 
500::999  and  1 :  :  4  9  9  respectively  below  FLIGHT .. flight# 

(=  { | 1 : : 9 9 9 | } )  on  the  IS-A  hierarchy.  Similarly, 

CANADA  :=  { | ' CANADA ' | }  l6-a  COUNTRY 
makes  CANADA  a  class  with  a  single  instance.  Presumably,  COUNTRY 
has  as  instances  many  other  strings  such  as  'USA',  ’CHINA’,  and 
'GREECE',  in  addition  to  ’CANADA’. 

It  is  now  possible  to  define  two  specializations  of 


FLIGHT 
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VARIABLE -CLASS  INTERNATIONAL-FLIGHT  U-a  FLIGHT  with 
cha.tiaatth.li>  tla, 

flight#:  INTERNATIONAL-FLIGHT#; 

end 

VARIABLE -CLASS  FLIGHT-WITHIN-CANADA  16 -a  FLIGHT  with 
chahactchli  tla> 

flight#:  FLIGHT# -WITHIN- CANADA ;  _ 

departure:  [[country:  CANADA |]  l6-a  FLIGHT .. departure ; 

destination:  [[country:  CANADA]]  li>-a  FLI GHT . . des tination 

end 

When  a  class  is  defined  "on-line”  in  terms  of  the  match-fix  operators 
{ | , | }  or  [[,!],  one  can  place  it  at  the  same  time  on  the  IS-A 
hierarchy,  as  illustrated  in  the  "departure"  and  "destination" 
properties  of  FLIGHT-WITHIN-CANADA.  Of  course,  since  the  aggregate 
class  defined  by  [[country:  CANADA]]  is  a  specialization  of 
FLIGHT .. departure  (  =  [|city:  CITY,  country:  COUNTRY!]),  it  has  two 
(not  one)  characteristic  properties,  as  "city"  is  inherited. 

According  to  the  definition  of  RESERVE-SEAT,  the  definitional 
complex  property 

< (PERSON,  FLIGHT),  reserve -seat ,  RESERVE -SEAT> 
is  part  of  the  TAXIS  program  being  constructed.  It  follows  then 
from  postulate  IV  (the  Structural  IS-A  Constraint)  that  any  combina¬ 
tion  of  specializations  of  the  classes  PERSON  and  FLIGHT  must  have  a 
"reserve-seat"  complex  property  whose  p-value,  a  transaction,  is  a 
specialization  of  the  transaction  RESERVE -SEAT .  Intuitively,  this 
means  that  the  "reserve -seat"  for,  say,  CHILD  and  INTERNATIONAL-FLIGHT 
must  have  at  least  the  prerequisites,  actions  and  results  of 
RESERVE-SEAT  and  possibly  more  of  each.  For  example,  suppose  that  we 
wish  to  enforce  a  (rather  conservative)  constraint  whereby  each  child 


24 


must  be  accompanied  by  his/her  guardian  on  an  international  flight. 

This  is  clearly  a  constraint  concerning  the  transaction 
(CHILD,  INTERNATIONAL -FLIGHT) . .  reserve-seat.  It  can  be  added 
to  that  transaction  as  a  prerequisite  as  follows: 

pn&n<iq  accompanied-by-guardian?  on 

(CHILD,  INTERNATIONAL-FLIGHT) . . reserve  -  seat  U 
[p. guardian,  f]  in-btanaz-o RESERVATION 

This  definition  adds  "accompanied-by-guardian?”  as  a  prerequisite 
property  of  the  transaction  (CHILD,  INTERNATIONAL-FLIGHT) . . reserve -seat 
which,  of  course,  also  inherits  all  properties  of  RESERVE -SEAT . 

As  another  example,  suppose  that  any  person  (adult  or  child) 
entering  Canada  must  be  a  citizen,  landed- immigrant  or  visitor: 

pnznzq  can- enter- Canada?  on 

(PERSON,  INTERNATIONAL -FLIGHT) . . reserve -seat  U 
p. status  tn6tancz-o{)  {  |  1  CITIZEN  LANDED -IMMIGRANT  '  , 
'VISITOR’ I }  on  not  f . destination  =  'CANADA' 


As  a  final  example  of  how  specializations  of  RESERVE-SEAT 
might  be  modified  to  suit  particular  combinations  of  specializations 
of  PERSON  and  FLIGHT,  suppose  that  the  income  tax  office  must  be 
notified  for  any  citizens  or  landed  immigrants  leaving  Canada: 

action  notify-income- tax-people  on 

(ADULT,  INTERNATIONAL -FLIGHT)  . .reserve-seat  l. 4 
li  (p. status  =  'CITIZEN'  on  p. status  =  ' LANDED- IMMIGRANT ’ 
and  f . departure . country  =  'CANADA' 
and  not  (f .destination. country  =  'CANADA') 
then  NOTIFY- INCOME -TAX -PEOPLE (p , f ) 

This  action  has  no  effects  if  its  Boolean  condition  is  not  true. 

Once  these  properties  have  been  added  to  their  corresponding 
transactions,  the  expression  (p , f) . reserve -seat  has  quite  different 
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meaning  depending  on  whether  p  is  an  adult,  a  child  or  just  a 
person  and  f  is  an  international  or  local  flight.  Generally, 

(p , f) . reserve  -  seat  =  (Type (p) , Type (f) ).. reserve  -  seat (p , f) 
where  Type (x)  returns  (one  of)  the  least  general  class  that  has  x 
as  an  instance.  If  there  is  more  than  one  such  class  then  it  is 
assumed  that  choosing  between  them  does  not  affect  the  value  or 
the  side-effects  caused  by  the  call. 

The  examples  presented  illustrate  the  following  points 
about  the  IS-A  relationship: 

1.  It  is  not  only  data  objects  that  can  be  organized  into  an 
IS-A  hierarchy  but  also  semantic  integrity  constraints, 
expressed  as  prerequisites,  results,  and  database 
actions . 

2.  Parts  of  the  IS-A  hierarchy  determine  the  structure  of 
other  parts  through  the  definition  of  properties.  For 
example,  the  part  of  the  IS-A  hierarchy  which  appears 
below  the  transaction  RESERVE-SEAT  is  structurally  homo¬ 
morphic  to  the  cross-product  of  the  IS-A  hierarchies 
which  appear  below  PERSON  and  FLIGHT.  This  is  a  direct 
consequence  of  the  Structural  IS-A  Constraint  and  it  can 
serve  as  a  powerful  guiding  principle  for  the  construction 
of  a  TAXIS  program. 
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4.  MORE  ON  CLASSES  AND  METACLASSES 

We  return  to  the  topic  of  classes  and  metaclasses  in 
order  to  provide  additional  details  about  them. 

4 . 1  Variable  Classes 

The  built-in  metaclass  VARIABLE-CLASS  has  the  special 

feature  that  only  its  instances  can  have  their  extensions  altered 

through  the  expressions  Zvue.h.£-obj  zc.£,  K move-object.  For  example, 

VARIABLE-CLASS  PASSENGERS  with 
p:  PERSON 

e.nc£ 

defines  an  instance  of  VARIABLE- CLASS  which  initially  has  no 
instances  of  its  own.  However, 

tnA&fit-o  bj  zct  tn  PASSENGERS  u)Z£k  p  john- smith 
adds  h  new  token  to  the  extension  of  PASSENGERS  with  "p"  p-value 
the  person  "j ohn-smith" ,  and  returns  that  new  token  as  value.  A 
token  x  can  be  removed  from  the  extension  of  a  class  C  through  the 
expression 

-teino  vz-o  bj  2.ct  x  tfsiom  C 

Note  that  when  a  token  is  added  to  the  extension  of  a  class,  it  is 
also  added  to  the  extensions  of  all  its  generalizations  and  when 
it  is  removed  from  a  class,  it  is  removed  from  the  extensions  of 
all  its  specializations.  Thus  postulate  III  for  the  IS-A  relationship 
is  never  violated  as  a  result  of  an  insertion  or  removal  of  a  token. 

In  addition  to  £vit><LH£- ob  j  nat  and  h.nmov<i-o  bj  e.c.£,  TAXIS 
provides  three  other  QUEL-like  ([7])  expressions  which  allow 
general  searches  of  the  extension  of  one  or  more  variable  classes. 

Thus  the  expression 


27 


ion  x  In  EMPLOYEE 
ion  y  In  MANAGER 

netnleve  -into  FATCATS  with  name  «-  x.name,  sal  +-  x.sal 
whene  x.dept  =  y.dept  and  x.sal  >  y.sal 

retrieves  into  the  variable  class  FATCATS  employees  making  more  than 
one  of  their  managers.  Note  that  the  assumption  (MANAGER  IS-A 
EMPLOYEE)  implies  that  MANAGER  has  the  properties  of  EMPLOYEE,  in 
particular  "sal"  and  "dept". 

In  addition  to  n etnleve,  append  and  delete  expressions 
are  also  provided  and  are  similar  in  form  and  semantics  to  n etnleve 
(or  corresponding  QUEL  commands) . 

Variable  classes  are  the  only  classes  which  are  allowed 
to  have  key  properties  .  Going  from  a  key  to  the  corresponding  token 
is  handled  in  terms  of  the  mechanisms  already  introduced.  Thus, 
if  "address-1"  is  a  particular  address, 

(’SMITH, JOHN, B ' ,  address -1) .person-id 
returns  either  the  person  identified  by  this  key  or  nothing. 

The  characteristic  factual  properties  of  a  variable  class 
instance  can  be  changed  through  the  update  openaton  For 

ins  tance , 

j  ohn-smi  th  .  age  ■*-  35 

changes  " j ohn- smith"s "age" from  whatever  it  was  to  35. 


4 . 2  Aggregate  Classes 

A  second  important  category  of  classes  consists  of  instances 
of  the  built-in  metaclass  AGGREGATE-CLASS.  The  extension  of  an 
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aggregate  class  is  determined  at  all  times  by  the  cross  product 
of  the  extensions  of  its  p- values.  For  example,  the  extension  of 
the  aggregate  class  [|city:  CITY,  country:  COUNTRY|]  is  the  cross- 
product  of  the  extensions  of  CITY  and  COUNTRY.  The  only  way  to 
change  the  extension  of  an  aggregate  class  is  to  change  the  extension 
of  one  of  its  p-values. 

Instances  of  aggregate  classes  can  be  referenced  but 
never  created  or  destroyed.  Thus 

[city:  ’TORONTO’,  country:  ’CANADA’] 
references  a  tuple  which  is  an  instance  of  any  aggregate  class  whose 
extension  includes  the  tuple  ('TORONTO',  'CANADA').  We  call  the 
tokens  referenced  through  the  matchfix  operators  [,]  aggsizgate,* . 

All  the  simple  properties  of  an  aggregate  class  are 
characteristic  properties  and  cannot  be  changed  for  any  one  aggre¬ 
gate.  However,  there  is  an  expression  in  TAXIS  which  allows  the 
identification  of  an  aggregate  related  to  a  given  one  w.r.t.  some 
of  its  components.  For  example,  if  x  is  the  aggregate  ['TORONTO', 
'CANADA']  then  the  expression 

x  but  city  'MONTREAL' 

identifies  the  tuple  obtained  from  x  by  replacing  its  "city"  p-value 
with  'MONTREAL'. 

4 . 3  Finitely-Defined  Classes 

Instances  of  the  built-in  metaclass  FINITELY-DEFINED- CLASS 
have  their  extensions  specified  once  and  for  all  at  the  time  they 
are  defined,  e.g. 

CANADIAN -METROPOLES  :=  { | ' MONTREAL ',' TORONTO VANCOUVER ' | } 
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or 

INTERNATIONAL-FLIGHT#  :=  { | 500:  :999| }  U -a  FLIGHT# 

Finitely- defined  classes  are  very  similar  to  PASCAL  scalar 
types.  For  instance,  the  functions  "succ"  and  "pred"  return  the 
successor  or  predecessor  of  an  instance  in  the  ordering  of  instances 
specified  by  the  class  definition.  Similarly,  there  are  special 
relations  "It",  "gt",  "le",  "ge"  which  compare  two  instances  of  a 
finitely  defined  class  w.r.t.  this  ordering. 

4 . 4  Test-Defined  Classes 

Aggregate,  finitely- defined  and  formatted- classes  are  all 
special  cases  of  the  general  collection  of  ned  cla.46eA. 

Such  classes  are  characterized  by  the  fact  that  membership  in  their 
extension  is  determined  by  a  transaction  defined  for  this  purpose: 

<  CANY ,  TEST-DEFINED-CLASS) ,  test,  TEST -TRANSACT I ON> 

This  complex  property  specializes  for  aggregate  classes  to 

< (AGGREGATE,  AGGREGATE  -  CLASS) ,  test,  TEST -AGGREGATE> , 
where  AGGREGATE  is  a  specialization  of  ANY  with  all  possible 
aggregates  as  instances.  Similarly,  we  have 

< (ANY ,  FINITELY-DEFINED-CLASS) ,  test,  FINITE-TEST) > 

and 

(STRING,  FORMATTED - CLASS ) ,  test,  FORMAT -TEST> , 
where  STRING’S  extension  contains  all  strings  and  TEST-AGGREGATE, 
FINITE-TEST  and  FORMAT-TEST  are  all  specializations  of  TEST-TRANSACTION. 
The  essence  of  these  three  transactions  was  already  given  in  the 
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discussion  of  aggregate,  finitely- defined  and  formatted  classes. 

For  instance,  TEST-AGGREGATE (x , C)  checks  that  the  components  of 
aggregate  x  are  instances  of  the  p-values  of  C’s  attribute  properties. 
FINITE-TEST (x , C) ,  on  the  other  hand,  checks  whether  x  is  one  of 
the  tokens  defined  to  be  in  the  extension  of  C.  Generally,  if  C 
is  a  test-defined  class,  then 

x  Instance-ofi  C  =  (Type (x) , Type (C) ).. test (x  ,C) 


Not  all  test  transactions  are  predetermined  as  they  are  for 
aggregate,  finitely-defined  and  formatted  classes.  For  example, 
we  can  define  the  metaclass 

metaclass  TRAVELLER-TO- CANADA-CLASS  Is -a  TEST-DEFINED-CLASS 


and  then  the  transaction 

transaction  TEST -TRAVELLER -TO -CANADA  Is -a  TEST-TRANSACTION  with 
parameter- Its t 

test :  (p ,  class)  ; 
locals 

p:  PERSON; 

class:  TRAVELLER-TO-CANADA-CLASS; 
returns 

rtrn,:  no  t{  get- ob  j  ect  x  rom  RESERVATION 
where (x .person  =  p  and 

x . flight .destination . country  =  'CANADA') 

=  nothing) 

end 


thereby  setting  up  the  definitional  property 

<  (PERSON,  TRAVELLER-TO-CANADA-CLASS),  test, 
TEST -TRAVELLER- TO -CANADA> . 


Now,  the  class  defined  by 

TRAVELLER-TO-CANADA-CLASS  TRAVELLER-TO- CANADA  Is-a  PERSON 
has  as  instances  all  person  who  have  booked  a  reservation  for  a 
flight  with  a  destination  in  Canada. 
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4 . 5  Expressions 

Expressions  can  only  appear  in  TAXIS  programs  as  p-values 
of  prerequisite,  action,  result  or  return  properties. 

Conditional,  block  and  looping  constructs  are  provided  in 
the  language  for  the  construction  of  compound  expressions  from 
simpler  ones. 

Expressions  are  classes  and  can  have  definitional  properties 
of  their  own  (which  associate  exceptions  with  them).  However, 
expressions  are  special  types  of  classes  in  two  respects: 

1.  Their  extension  is  invariably  empty 

2.  Their  IS-A  hierarchy  is  determined  by  the  following  rule: 

If  <T,p,E>  and  <T’,p,E’>  and  (T  IS-A  T') 

then  (E  IS-A  E’),  where  T,T'  are  transactions,  E,E'  expressions 
Thus  there  is  no  need  to  specify  explicitly  the  IS-A  hierarchy  of 
expression  classes  since  that  is  determined  by  the  transactions 
to  which  they  are  attached. 

The  fact  that  expression  classes  have  empty  extensions 
means  that  Postulate  III  (the  Extensional  IS-A  Constraint)  is 
trivially  satisfied  for  expressions.  As  a  replacement  we  propose 
the  following  postulate. 

Postulate  III*  (Behavioural  IS-A  Constraint) 

(a)  If  E,  E’  are  Boolean  expressions  and  (E  IS-A  E')  then  it 
must  be  that  E  -*  E  ’  (E  implies  ET)  and  E  causes  at 
least  the  side-effects  of  E'. 

(b)  If  E,  E’  are  non-Boolean  expressions  and  (E  IS-A  E')  then 

it  must  be  that  when  value  (E)  f  nothing,  value (E)  =  value(E') 
and  moreover  E  causes  at  least  the  side-effects  of  E'. 

This  discussion  does  not  apply  to  expressions  involving  @,[|,|] 
and  { | , | }  which  define  new  classes  and  are  evaluated  at 
compilation  time. 
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Consider,  for  example,  a  specialization  of  the  RESERVE- 
SEAT  transaction,  say  T,  for  which  the  prerequisite  "seats - left?" 
must  be  redefined.  It  makes  sense,  according  to  the  Behavioural 
IS-A  Constraint,  to  redefine  it  as 

seats-left?  on  T  f-6  f.seats-left  >10, 
since  (f.seats-left  >  10)  -*  (f.seats-left  >  0).  The  redefinition, 
however , 


seats-left?  on  T  16  f.seats-left  >  0  on.  p.age  <  2 
is  inappropriate  because 

(f.seats-left  >  0  o^t  p.age  <  2)  f  f.seats-left  >  0) 


Similarly,  the  block  expression  E  defined  by 
begin 

Jonh  e>it- ob  j ect  -In  RESERVATIONS  with 

person  *-  p,  flight  *-  f; 
in*  efit-o  bj  ec.t  In  PASSENGERS  with  p  p; 

end 


can  be  made  a  specialization  of  RESERVE-SEAT. .make-reservation 
because  its  side-effects,  which  involve  two  insertions,  include  those 
of  RESERVE-SEAT . .make-reservation .  The  same  statement  is  not  true 
if  the  first  ln-4  &A.t- o  b  j  not  expression  is  deleted  from  E. 

The  Behavioural  IS-A  Constraint  is  formalized  in  [25] 
and  its  consequences  are  discussed. 


4 . 6  Transactions 

We  have  already  presented  the  basic  categories  of  properties 
one  can  associate  with  a  transaction.  Through  prerequisites,  actions 
and  results,  the  TAXIS  user  can  "factor  out"  a  transaction  body 
into  semi - independent  constraint  checks  and  actions  that  may  be 
associated  with  a  transaction  directly,  during  its  definition,  or 
indirectly,  through  inheritance. 
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4 . 7  Exceptions 

We  have  adapted  Wasserman’s  [21]  procedure-oriented 
exception-handling  mechanism  with  modifications  that  allow  exceptions 
and  exception-handling  to  be  treated  within  the  framework  of  classes, 
properties  and  the  IS-A  relationship. 

Exception  classes  are  defined  and  organized  into  an  IS-A 
hierarchy,  like  all  other  classes.  The  built-in  metaclass 
EXCEPTION-CLASS  has  as  instances  all  exception  classes  which  are 
also  specializations  of  the  built-in  class  ANY-EXCEPTION .  For  a 
particular  TAXIS  program,  or  a  collection  thereof,  we  may  have 
below  ANY-EXCEPTION  the  classes  SECURITY-EXCEPTION,  CONSTRAINT- 
EXCEPTION  etc.  Below  these,  one  may  wish  to  attach  exception  classes 
such  as 

EXCEPTION-CLASS  NO-SEATS-LEFT  U-a  CONSTRAINT-EXCEPTION  with 
attribute.- ptLopzfitlzA 
pers  :  PERSON; 
fit  :  FLIGHT; 

end 

When  an  instance  of  this  exception  class  is  created  (i.e.  is  fialA&d) 
its  factual  properties  are  assigned  p-values  through  which  one  can 
obtain  information  about  the  circumstances  under  which  the  exception 
was  raised. 

Exceptions  are  raised  when  a  prerequisite  or  result 
expression  evaluates  to  a  value  other  than  tfiu.2,.  To  specify  which 
exception  is  raised,  one  must  associate  with  a  prerequisite  or 
result  p-value,  which  is  always  an  expression  class,  an  exception 
class.  For  RESERVE  -  SEAT ,  for  example,  this  can  be  done  either  by 
replacing  the  ’’seats - lef t ?"  property  of  the  transaction  with 
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£fiani>ac.£to  n  RESERVE -SEAT  u)££k 

•  •  • 

seats-left?  :  £.seats-le£t  >  0  exc 

NO -SEATS -LEFT (pers:p,£lt:f) ; 

•  •  • 

end 


or  by  adding  a  definitional  property  to  the  p-value  of  the 
"seats-left?"  property  with 

o.xce.p££o  n-pfiopo.fi£y  exe  on  RESERVE-SEAT  ..  seats  -  left?  £-6 

NO-SEATS-LEFT  (pers:p,  flt:f) 

In  both  cases,  the  associations  "pers:p",  "flt:f"  indicate  the 
p-values  to  be  assigned  to  the  factual  properties  of  the  NO-SEAT-LEFT 
instance  raised  when  the  prerequisite  "seats-left?"  fails. 

When  an  exception  is  raised  within  a  transaction  T,  it  is 
up  to  the  caller  of  T  to  specify  what  should  be  done  to  handle  it. 
Such  specifications  come  in  the  form  of  complex  properties  called 
o.xoo.p£ton-kandlo.fu>  that  take  as  subjects  an  expression  E  and  an 
exception  EXC  and  p-value  an  exception  handling  transaction  T^ . 

When  an  instance  of  EXC  is  raised  during  the  evaluation  of  E,  then 
T^  is  called  with  the  exception  raised  as  its  only  argument. 

Suppose,  for  example,  that  the  transaction  CALLER  calls  RESERVE-SEAT 
or  one  of  its  specializations  during  the  execution  of  one  of  its 
actions,  say  "act".  To  indicate  that  the  transaction  FIND- 
ALTERNATIVE  should  be  called  if  the  exception  NO-SEATS-LEFT  is 
raised,  we  write 

tfian^aotto  n  CALLER  with 

•  •  • 

aottonA 

u  •  • 

act:  reserve-seat (pi ,  fl) 

nxo-kandto.fi  eh  faofi  NO-SEATS-LEFT  £4 

FIND-ALTERNATIVE 


end 
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which  defines  the  complex  property 

< (reserve-seat (pi ,  fl) , NO-SEAT-LEFT) ,  eh,  FIND-ALTE RNAT I VE > 
Now,  if  an  instance  of  NO-SEATS -LEFT  is  raised  during  the  evaluation 
of  reserve-seat (p ,f) ,  FIND-ALTERNATIVE  will  be  called  with  the 
newly- created  exception  instance  as  argument.  Froir  the  properties 
of  this  instance,  FIND-ALTERNATIVE  will  determine  the  circumstances 

of  the  exception  and,  we  hope,  what  should  be  done. 

\ 

Treating  exceptions  and  exception-handling  in  terms  of 
classes,  properties  and  the  IS-A  relationship  means  that  the  already 
existing  IS-A  hierarchy  of  data  classes  and  transactions  can  be 
used  to  structure  exception-handling  within  any  one  TAXIS  program. 

We  will  illustrate  this  point  by  extending  the  example  we  have 
used  so  far  so  that  if  a  NO-SEATS-LEFT  instance  is  raised  for  a 
child,  it  is  not  only  for  the  child  that  an  alternative  is  found 
but  also  for  his/her  guardian.  First,  we  create  a  specialization 
of  NO-SEATS-LEFT: 

dxcaption  NO-SEAT-FOR-CHILD  U-a  NO-SEATS-LEFT  with 
attfisibutz  pfiope.tit'ie.A 
guardian:  ADULT; 

end 

Then  we  redefine  the  exception  property  "exc"  of  the  "seats -left?" 
prerequisite  for  the  transaction  (CHILD,  INTERNATIONAL-FLIGHT)., 
reserve -seat 

Q.xc£pti.on-pfLOp<ifity  exc  on  (CHILD,  INTERNATIONAL-FLIGHT).. 

reserve -seat ..  seats  -  left  ?  f-4 
NO- SEAT-FOR-CHILD (pers :p ,  flt:f,  guardian:  p. guardian) 

Finally,  we  augment  the  exception  handler  FIND-ALTERNATIVE  for  the 
exception-handling  property  "eh"  of  CALLER.. act  and  NO-SEAT-FOR-CHILD 
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cult-ion  find-alternative-for-guardian- too  on 
(CALLER . .act,  NO-SEAT-FOR-CHILD) . .eh  U 
/*  remove  the  child’s  guardian  from  the  flight  fit 
and  reserve  a  seat  for  him/her  as  well  on  the 
alternative  flight  selected  */ 

We  will  not  present  code  for  the  new  action  defined  for 
the  exception-handler  of  NO-SEATS-LEFT  exceptions.  It  is  worth 
noting,  however,  that  the  IS-A  hierarchy  of  exception-handlers 
is  patterned  after  that  of  PERSON,  FLIGHT  and  their  specializations, 
along  with  the  transactions  that  operate  on  them. 

When  an  exception-handling  transaction  completes  its 
execution,  control  returns  to  the  point  where  the  exception  was 
raised  and  the  expression  following  the  prerequisite  or  result 
where  the  exception  was  raised  is  evaluated.  Thus,  each  prere¬ 
quisite  or  result  expression  E  can  be  interpreted  as  a  conditional 
expression 

E  than  ni.1  ef-6£_  _  _ 

where  the  blank  is  filled  by  the  caller  of  the  transaction  where 
E  appears . 
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5.  CONCLUSIONS 

Several  other  research  efforts  are  related  and/or  have 

influenced  our  work.  PLAIN  [22]  is  one  of  the  few  examples 

of  a  language  designed  with  goals  similar  to  those  of  TAXIS.  The 

main  difference  between  the  two  languages  is  that  PLAIN  does  not 

use  the  IS-A  relationship  as  a  structuring  construct  for  data  or 

procedures.  We  have  adapted  PLAIN’S  exception-handling  mechanism, 

but  modified  it  to  make  it  consistent  with  the  TAXIS  framework. 

% 

Moreover,  due  to  the  structure  of  transactions,  we  have  managed  to 
restrict  the  kind  of  situation  under  which  an  exception  is  raised 
to  failure  of  a  prerequisite  or  a  result. 

A  recent  proposal  in  [13]  for  the  use  of  type  hierarchy 
is  basically  identical  to  the  IS-A  hierarchy  described  in  this  paper. 
Our  work  seems  to  differ  from  Mealy's  only  in  that  his  is  applied 
to  ELI  data  structuring  mechanisms  [23]  rather  than  the  design  of 
an  application  language. 

Our  IS-A  hierarchy  is  also  similar  to  the  generalization 
hierarchy  proposed  in  [19],  although  we  do  not  use  the  "unique  key” 
assumption  they  impose  on  their  hierarchy,  nor  do  we  use  their 
notion  of  image  domains  which  defines  a  particular  implementation 
of  the  IS-A  relationship  within  a  Relational  database  framework. 
Another  difference  between  IS-A  and  the  generalization  hierarchy 
proposed  by  the  Smiths  is  that  it  is  possible  to  redefine  a 
property  for  a  specialization  of  a  class  in  TAXIS  (subject  to  the 
Structural  IS-A  Constraint) ,  but  that  is  not  the  case  for  the 
generalization  hierarchy.  We  consider  this  ability  to  redefine 
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properties  (by  specializing  their  p-values)  an  important  component 
of  the  structuring  mechanism  offered  by  the  IS-A  relationship. 

[ 6  ]  and  [  9  ]  have  also  proposed  data  models  which  offer  an  IS-A 
relationship . 

The  treatment  of  the  INSTANCE-OF  relationship  in  TAXIS 
is  based  on  the  treatment  this  relationship  receives  in  PSN 
(Procedural  Semantic  Network  formalism)  described  in  [10],  [11]. 
However,  PSN  allows  an  arbitrary  number  of  metaclass  levels, 
as  well  as  the  possibility  for  a  class  to  be  an  INSTANCE-OF  itself. 
We  have  avoided  such  a  scheme  because  experience  has  taught  us 
that  two  levels  of  classes  are  sufficient  for  most  situations. 

[8  ]  and  [20]  also  offer  proposals  concerning  the  INSTANCE-OF 
relationship . 

The  high  level  relational  database  operations  of  QUEL 
(e.g.  retrieve),  [7],  are  very  similar  to  the  compound  expressions 
used  to  manipulate  variable  classes.  Obviously,  variable  classes 
share  many  features  with  relations  of  the  Relational  Model.  In 
embedding  variable  classes  in  a  programming  language  we  have 
taken  a  very  different  approach  from  that  described  in  [17]  which 
treats  relations  as  data  objects  that  can  be  created  dynamically 
as  results  of  relational  operations.  Instead,  in  TAXIS  no 
(variable  or  otherwise)  can  be  created  as  results  of  run-time 
operations.  We  rejected  Schmidt’s  proposal  very  early  in  our  work 
because  it  raises  a  design  dilemma  for  which  do  not  have  a  good 
solution:  either  we  allow  the  inclusion  of  classes  in  TAXIS  programs 
that  do  not  have  the  usual  TAXIS  semantics  Ci*e.  properties  and  a 
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position  on  the  IS-A  hierarchy) ,  contrary  to  design  principle 
(2)  of  section  1,  or  we  include  run-time  facilities  for  obtaining 
the  TAXIS  semantics  for  derived  classes,  as  done  in  [15], 
contrary  to  design  principle  (4). 

Finally,  Abrial's  work  [1  ]  has  been  very  influencial 
in  directing  us  towards  "data  models"  or  "representation  schemes" 
([26])  which  offer  procedural  as  well  as  data-oriented  facilities 
for  the  definition  of  a  model. 

From  an  AI  point  of  view,  our  work  is  a  direct  descendent 
of  PSN,  with  much  of  the  power  of  the  formalism  left  out  to 
accommodate  the  design  principles  of  TAXIS. 

As  far  as  contributions  are  concerned,  we  believe  that 
this  paper  has  provide4  evidence  on  how  a  framework  involving 
classes,  properties  (of  classes) ,  the  IS-A  relationship,  and  to  a 
lesser  extent  the  INSTANCE-OF  relationship,  can  be  used  to  account 
not  only  for  data-oriented  (declarative,  to  use  the  terminology 
in  [26])  aspects  of  a  model  of  some  enterprise,  but  also  procedural 
ones,  e.g.  expressions,  exceptions  and  transactions. 

Acceptance  of  the  TAXIS  framework  for  the  design  of  IISs 
can  have  far-reaching  consequences: 

1.  It  provides  a  methodology  for  dealing  with  semantic 
integrity  constraints,  which  in  TAXIS  are  treated  as  prerequisite 
and  result  properties  of  transactions  and  are  organized  into  an 
IS-A  hierarchy  consistent  with  those  defined  for  data  classes 
and  operations  on  them. 
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2.  It  provides  a  general  design  methodology  based  on 
"stepwise  refinement  by  specialization"  as  opposed  to  "stepwise 
refinement  by  decomposition"  [24],  which  has  been  the  main  design 
tool  used  so  far  in  program  development.  For  data  structures, 

an  account  of  what  stepwise  refinement  by  specialization  means 

\ 

and  how  it  relates  to  stepwise  refinement  by  decomposition  has 
already  been  given  in  [19].  TAXIS  proposes  a  similar  framework 
for  all  aspects  concerning  a  program  design,  not  just  its  data 
structures.  Further  evidence  for  the  importance  of  this 
notion  is  provided  in  [25], 

There  are  four  directions  along  which  research  on  TAXIS 
is  proceeding  today: 

1.  Formalization:  TAXIS  offers  some  unusual  constructs 

and  a  formal  definition  of  what  they  mean  appears  highly  desirable. 
[25]  provides  an  axiomati zation  of  the  language  as  well  as 
a  denotational  semantics  to  account  for  these  constructs.  A  by¬ 
product  of  this  work  is  the  ability  to  prove  TAXIS  programs  correct 
w.r.t.  some  logical  specification. 

2.  Definition  of  Input/Output  Facilities:  TAXIS  does  not 
offer  at  this  time  input/output  facilities.  To  extend  it  in  order 
to  have  it  provide  such  facilities  we  are  considering  the  possi¬ 
bility  of  using  the  same  framework  (classes  et  al.)  for  the 
definition  of  all  syntactic  and  pragmatic  aspects  of  a  user  interface. 

3.  Implementation:  a  TAXIS  parser  and  code  generator,  and 
possibly  an  interactive  system  through  which  a  designer  can  use 
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TAXIS  is  an  important  step  towards  testing  the  language.  Also, 
there  are  important  theoretical  problems  such  as  the  mapping  of 
variable  and  transaction  classes  into  relations  and  procedures 
respectively . 

4.  Applications:  apart  from  the  design  of  individual  IISs 
in  TAXIS,  we  wish  to  explore  the  possibility  of  extending  TAXIS 
to  make  it  suitable  for  the  design  of  IISs  from  one  particular 
applications  area,  say,  accounting  or  inventory  control. 
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CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A.  Bernstein  and  C.  Beeri,  September  1976 

*  CSRG-74  A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A.  Schuster,  October  1976 

CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
CALCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 

CSRG-76  SOFTWARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  Wortman,  November  1976 
[IEEE  Transactions  on  Software  Engineering,  v.SE-3,  n.4,  July  1977] 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 
G.  Scott  Graham,  January  1977 

CSRG-78  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis  (ed.),  February  1977 

CSRG-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LALR 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson,  April  1977 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-80  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  (ed.),  Fifth  Edition,  May  1977 

CSRG-81  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY 
FOR  IFIP  WORKING  GROUP  2.3 

Sol  J.  Greenspan  and  J.J.  Horning  (eds.),  First  Edition,  May  1977 
CSRG-82  NOTES  ON  EUCLID 

edited  by  W.  David  Elliot  and  David  T.  Barnard,  August  1977 

CSRG-83  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

CSRG-84  TOWARD  PROGRAM  ILLUSTRATION 

Edward  Yarwood,  September  1977 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-85  CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER 
SYSTEMS 

Edward  D.  Lazowska,  September  1977 
[Ph.D.  Thesis,  DCS,  1977] 
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CSRG-86  MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR  QUEUEING 
NETWORK  MODELS 
Martin  G.  Kienzle,  October  1977 

[M.Sc.  Thesis,  DCS,  1977;  Proc.  Int.  Symp.  on  Modelling  and  Performance 
Evaluation  of  Computer  Systems,  Vienna,  1979] 

CSRG-87  'OLGA1  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H.  Trickey,  D.M.  Lewis,  E.S.  Lee, 

P.I.P.  Boulton,  November  1977 

CSRG-38  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  Silverberg,  January  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-89  ON  THE  IMPLEMENTATION  OF  RELATIONS:  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt,  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 
SEMANTIC  INTEGRITY 
Michael  Lawrence  Brodie,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-92  STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP): 

AN  INTRODUCTION 

by  William  Buxton,  Guy  Fedorkow,  with  Ronald  Baecker, 

Gustav  Ciamaga,  Leslie  Mezei  andK.C.  Smith,  June  1978 

CSRG-93  A  DEVICE-INDEPENDENT,  GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves,  August  1978 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-94  ON  THE  AXIOMATIC  VERIFICATION  OF 
CONCURRENT  ALGORITHMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Thesis,  CSRG,  October  1978] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  1.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.).  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 

CSRG-105  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTERACTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos,  Philip  A.  Bernstein,  Harry  K.T.  Wong, 
July  1979 


